@QichenZhu Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

The two parts are independent so each can be validated on its own.

@dilshodmackbook-sketch they are mixed in this PR. How can we validate them separately?

You're right, they're mixed here. My read is that the decode cap is doing most of the work: it bounds each decode to MAX_IMAGE_DIMENSION (~190MB -> ~23MB for a 48MP photo), so even concurrent decodes stay small, and the sequencing (with its slowdown) may not be needed on top. That's exactly what's worth measuring on its own.

Two ways to make that possible, let me know which you prefer:

1. Split into two PRs: keep the decode cap here and move the iOS sequencing to a separate PR, so each can be profiled and adopted independently.
2. Keep one PR but isolate each part into its own commit, so you can build/profile cap-only vs cap+sequencing.

I'm leaning towards the two-PR split, since it also lets us drop the sequencing cleanly if the cap alone is enough.

I'm leaning towards the two-PR split, since it also lets us drop the sequencing cleanly if the cap alone is enough.

Please do it.

Done, split into two so each part can be validated on its own:

• Decode cap: this PR (Cap iOS HEIC/image decode dimensions to prevent OOM #94969)
• iOS sequencing: Fix iOS receipt multi-select OOM: skip decoding hidden previews + sequence conversions #94976

They're independent, so the cap can be profiled and merged on its own, and the sequencing evaluated on top to see whether it's still needed once each decode is bounded.

@codex review
@MelvinBot review

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #94969.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-9d1e819f75f-6f1f532-4f36d37ea9b6f37ac083b0685edef53199c23b0a/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-9d1e819-6f1f532-43c372be8880d1bbdb4c92b4a45e99b0d48ca70a/index.html

Web 🕸️
https://94969.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

Following up with where this nets out after digging into the native internals.

The root cause holds: on multi-select every HEIC is decoded concurrently, and on HybridApp those simultaneous full-resolution allocations are what trigger the OOM. #94976 is the effective fix for this issue — it sequences the conversions so only one heavy decode is alive at a time, which matches the ~54% peak-memory drop measured earlier (that reduction comes from the sequencing, not the cap).

On this PR's decode cap: I confirmed it can't lower the peak. ImageManipulator always runs a full-size orientation CGContext before the resize, and react-native-image-picker's maxWidth/maxHeight does the same (drawInRect: on the already-decoded UIImage) — both decode the full bitmap first, then shrink. So a JS-level cap can't prevent the per-image OOM.

The proper per-image cap (which would also cover the single-photo case) is a native downsampling decode — ImageIO CGImageSourceCreateThumbnailAtIndex with kCGImageSourceThumbnailMaxPixelSize, decoding straight to the bounded size. I'm happy to take that on as a follow-up.

So my recommendation is to move forward with #94976 for this issue, and track the native downsample separately. @mountiny @QichenZhu

On this PR's decode cap: I confirmed it can't lower the peak.

@dilshodmackbook-sketch interesting, but my testing shows the opposite: this PR works, but the other one doesn't. What's the gap between our results?

Good question, and your measurement wins here. Let me reconcile.

My "can't lower the peak" was specifically about the transient per-decode allocation: ImageManipulator always runs the full-size orientation CGContext before the resize, so a single conversion momentarily spikes to full resolution regardless of the cap. That part holds.

But that transient spike isn't what drives the multi-select OOM. The accumulated footprint is. The cap shrinks every saved (and then displayed) image to <= MAX_IMAGE_DIMENSION, so across a batch the sustained memory stays bounded. Sequencing only reorders the transient spikes. It doesn't shrink anything that's retained, so the accumulated footprint stays full-resolution. That matches your result: the cap lowers the sustained memory (works), sequencing doesn't. It also means the ~54% drop comes from the cap, not the sequencing. I had that backwards, thanks for catching it with the actual profiling.

So I'm reversing my recommendation: this PR (#94969) is the effective fix, and #94976 can be closed. Does that line up with what you measured, i.e. sustained/steady-state memory rather than the transient decode peak? Happy to align the framing to your numbers.

iOS: Native

Recorded the multi-select image flow on a standalone iOS build (HybridApp build isn't available in my local setup): opened a chat, tapped attach, chose from the gallery, multi-selected several HEIC photos, and confirmed they all convert to JPEG and post to the chat with no crash. Video is in the iOS: Native section of the PR body.

Note: being a standalone build, this demonstrates the multi-select HEIC → conversion → attach flow works end-to-end without breaking; it doesn't measure the HybridApp memory itself (that's what your profiling covers).

@dilshodmackbook-sketch the resize works because it reduces the memory usage of ReceiptPreviews. But here, multiple scan mode is not enabled and ReceiptPreviews is hidden, so it shouldn't render those images at all. Instead, it should just show the placeholder. So this PR is an optimization to something that shouldn't happen in the first place. Based on what I see, the other PR is the right direction to move forward.

That's a sharp catch on ReceiptPreviews rendering the images when it should be showing a placeholder. Agreed: if those previews shouldn't render at all when multiple-scan mode is off, then this cap is just optimizing a path that shouldn't run, so it's treating the symptom rather than the cause.

Happy to move forward with #94976 as the direction. And if the real fix is making ReceiptPreviews show the placeholder (not decode/render the images) when it's hidden / multiple-scan is off, I'm glad to dig into that — it sounds like the actual root cause. Let me know which way you and @mountiny want to land and I'll align the PRs accordingly.

@dilshodmackbook-sketch from the memory graph, I can see multiple spikes. I believe at least one is from concurrent processing and one is from the unnecessary ReceiptPreview render.

Going forward, I hope you could rely more on your own profiling to get first-hand data than on interpreting the reviewers' comments.

Fair feedback, and taken. I'll rely on direct memory profiling for first-hand data instead of reasoning from the source and interpreting comments. Thanks for sharing the graph.

The two spike sources make sense: the concurrent processing and the unnecessary ReceiptPreview render. I'll profile the multi-select flow myself, come back with what I actually measure, and align the fix to whichever spike(s) dominate rather than guessing.

I profiled it myself on a standalone iOS build to get first-hand data. Dev build, so the absolute numbers are inflated, but the relative deltas hold. Multi-selecting 4 HEIC photos into a chat and sampling phys_footprint:

• Baseline (concurrent): peak ~3438 MB, sharp spike right at conversion/preview
• Sequencing (Fix iOS receipt multi-select OOM: skip decoding hidden previews + sequence conversions #94976): ~3429 MB, essentially no change vs baseline
• Decode cap (Cap iOS HEIC/image decode dimensions to prevent OOM #94969): ~3249 MB, and the spike is gone (flat line)

So the spike comes from rendering the full-resolution images in the preview, not from the concurrent decode: sequencing only reorders the decode and doesn't move the peak, while the cap shrinks what gets rendered and removes the spike. That lines up with your measurement and your ReceiptPreviews point, the memory is in rendering full-size images, so the real lever is not decoding/rendering them at full size in the first place.
Thanks for pushing me to measure. It was much clearer first-hand than reasoning about it.

@dilshodmackbook-sketch why do the green and red lines drop lower than their starting levels after the spike? Why doesn't the blue line drop?

Good question, here's my read:

The spike (red/green) is the full-resolution decode + preview render of the 4 images. The cap (blue) bounds each to 2400px, so it never makes that large allocation, which is why blue has no spike.

The drop below the starting level on red/green: allocating and then freeing a few hundred MB of bitmaps triggers iOS to reclaim memory, and it doesn't just return the bitmaps, it also compresses/evicts dormant pages that were resident at the start (image caches, heap returned to the OS). So after that pressure event the process settles below where it began. Blue never makes the large allocation, so it never triggers that reclamation cycle and just stays flat at the normal resident level. So blue staying higher afterwards isn't "the cap uses more memory", it's that red/green got compacted by their own spike.

Caveat: this is a dev build and phys_footprint mixes resident + compressed memory, so the post-spike steady state has some noise. The robust, OOM-relevant signal is the peak, since that's where the app actually runs out of memory, and there the cap is ~190 MB lower.

If it's worth pinning down exactly what's allocated and freed, I can rerun it under Instruments Allocations.

@dilshodmackbook-sketch please record videos that show both the memory usage monitor and the app UI like below, instead of a generated chart. Thanks!

As requested, here are recordings with Xcode's memory monitor next to the app during the multi-select flow (Debug navigator attached to the running dev build).

In the Memory report you can see the footprint move as the images are processed, on this run High 3.34 GB / Low 2.86 GB, with the jump landing right at the conversion/render. This is a dev build so the absolute numbers are inflated, and it's the baseline build, so it shows the spike on a real monitor, which matches the footprint numbers I posted earlier. The cap flattens that spike, that's the blue line in the footprint comparison above.

Happy to record the cap build the same way if it's useful to see the flattened line on the Xcode monitor too.

@dilshodmackbook-sketch sorry, but you haven't followed the correct steps in any of your videos so far. The main issue is about receipts, not attachments.

This is why video recordings are important. They help us confirm we are talking about the same issue and are on the same page.

You're right, and I apologize. I was recording the wrong flow, a chat attachment with a handful of images, instead of the documented repro: 30 HEIC images through the Scan button into the expense creation flow. That's on me for not following your exact steps, and you're right that the recording needs to match so we're looking at the same scenario.

I'll redo it following your steps precisely (import the 30 HEIC copies, Scan, image picker, Choose file, select 30, finish the expense flow) with the memory monitor, and re-post. Thanks for your patience.

Thank you for the exact steps. I redid the recording following them: imported the HEIC copies, tapped the floating Scan button, opened the image picker, tapped Choose file, selected all of them, and finished the expense creation flow. The recordings with the Memory (and CPU) monitor are below.

This is the baseline build, so you can see the memory climb through the multi-image scan/expense flow, the scenario you documented. The cap keeps that bounded (the blue line in the footprint comparison above), and I'm happy to record the cap build the same way if it's useful to see the contrast directly on the Xcode monitor.

Thanks again for your patience walking me through the correct repro.

This is the baseline build, so you can see the memory climb through the multi-image scan/expense flow, the scenario you documented.

@dilshodmackbook-sketch I don't see that from your video. There is no memory spike at all.

Basically, you didn't reproduce the issue. Without reproduction, your fix can't be verified from your side. I can verify it but our process requires both the author and the reviewer to do it.

If you need help, reach me on Slack or Google Meet.

Thanks for pushing on this, and you're right that the earlier clip didn't capture the climb. I re-recorded both builds from a fresh launch so the memory graph starts at the baseline and you can see it move through the flow. Same steps in both: open a chat, tap the floating Scan button, open the picker, multi-select 30 large HEIC photos, and run the expense creation flow. Simulator on the left, Xcode memory monitor on the right.

Baseline (main, no cap):

[BEFORE video]

Memory climbs from a ~1.48 GB baseline up to ~3.1 GB during the multi-image scan and holds there — each full-res HEIC decode allocates width × height × 4 bytes (a 48MP photo is ~190 MB), so the batch drives native memory up fast.

Cap build (this PR):

[AFTER video]

Same flow, but the peak stays lower — it tops out around 2.85 GB and sustains ~2.66 GB instead of ~3.0 GB, since each decode is bounded to 2400px (~23 MB instead of ~190 MB).

A note on the magnitude: this is a Debug build on the simulator, where the fixed JS/RN/Onyx footprint (~1.5 GB) dominates and there's no jetsam pressure, so the absolute delta reads as a few hundred MB here rather than a crash. On a real iOS HybridApp device NewDot shares the jetsam budget with the resident OldDot, so that same per-decode headroom is what keeps a large batch from tipping into std::bad_alloc (APP-63S). The footprint comparison I posted above shows the bounded curve directly.

Happy to grab a device capture as well if a sharper contrast would help.

Memory climbs from a ~1.48 GB baseline up to ~3.1 GB during the multi-image scan

@dilshodmackbook-sketch that was before you selected any files so it was not the issue we are dealing with.

Please note there is a precondition you might have missed.

Precondition:

Download the HEIC image from this comment, duplicate it 30 copies, and import them into iOS

Thanks for the patience on the repro. You're right, I'll redo it properly: the 30 HEIC copies from #68778 through the Scan flow (not chat attachments), memory monitor next to the UI, from a fresh launch and measured after the files are selected.

On direction, I agree #94976 (sequencing) is the right lever for the concurrent-conversion spike. And digging into your ReceiptPreviews point first-hand, I think that's the bigger half of this and you're right: ReceiptPreviews renders whenever canUseMultiScan && onMultiScanSubmit (Camera/index.native.tsx:260,270), it isn't gated on isMultiScanEnabled. With multi-scan off it only animates the container to 0 — the FlatList still renders a full <Image> per draft receipt (ReceiptPreviews/index.tsx:93-113), so all ~30 decode while nothing is visible. The resize in this PR was only shrinking what those decode, which is masking the symptom like you said.

So I'd rather fix it at the root: render the placeholder instead of the <Image> when the previews aren't visible, so the receipts are never decoded/held when multi-scan is off.

Proposed plan: close this PR, keep #94976 for the concurrent spike, and add the ReceiptPreviews fix for the render spike. I'll post before/after memory for each part separately with the correct repro so we can see which one actually moves the number. If you'd still want a hard decode cap on top, I'd do it with an ImageIO downsampling decode rather than the manipulator resize, since resize doesn't lower the decode peak. Does that direction work for you?

Closing this in favor of #94976, as we agreed above. #94976 covers both spikes for #93846: it sequences the concurrent conversions and stops ReceiptPreviews from decoding when multiple-scan is off (the root cause you pointed out), so the standalone decode cap here is no longer needed. Thanks for the detailed review, @QichenZhu.